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Aligning  Net-Centric  Practice  with  Net-Centric  Technology: 

A  Way  Forward 
(Abstract) 


Implementing  the  Net-Centrie  Operations  (NCO)  vision  in  support  of  enhaneed  eommand 
and  eontrol  presents  teehnieal,  operational,  and  eultural  ehalienges.  The  teehnieal 
ehallenges  are  being  addressed  by  both  industry  and  the  Department  of  Defense  pushing 
the  state  of  the  art  further  ahead.  However,  in  many  eases  the  teehnology  “art”  is  too  far 
ahead  of  the  DoD  policy  and  management  “practice”.  In  fact,  technology  vendors 
offering  products  to  help  in  the  management  aspects  of  network  enabled  systems  and 
services  often  find  their  solutions  are  in  search  of  clearly  defined  problems.  This 
misalignment  exists  because  a  DOD  enterprise  level  NCO  “operating  model”  has  not 
been  clearly  articulated  to  demonstrate  how  consumers  and  providers  of  net-centric 
services  will  interact.  More  than  a  Concept  of  Operations  (CONOPS),  which  tends  to 
describe  an  optimal  end  state,  an  operating  model  should  be  a  framework  to  allow 
emergent  behavior  to  first  grow  and  then  sustain  a  net-centric  environment. 

Consequently,  an  NCO  operating  model  must  address  architectural,  policy,  governance, 
performance  monitoring,  and  cultural  issues  and  practices.  However,  as  noted  above  the 
operating  model  is  itself  a  transformational  model.  It  cannot  prescribe  a  “to-be”  world  to 
any  degree  of  specificity.  Instead,  the  operating  model  establishes  the  tenets  of  policy 
and  governance  that  can  help  align  emerging  technology  to  fulfill  the  vision  of  NCO. 
Once  defined  and  set  in  motion,  the  operating  model  presents  a  way  forward  to  defining 
emerging  NCO  capability  requirements;  selecting  and  implementing  the  enabling 
technologies;  and  extending  the  NCO  environment  to  further  Defense  component  and 
agency  domains. 
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Aligning  Net-Centric  Practice  with  Net-Centric  Technology: 

A  Way  Forward 


Introduction 

The  purpose  of  this  paper  is  to  present  a  eoneeptual  approaeh  and  praetieal 
reeommendations  for  eoneeiving  and  implementing  a  Net-Centrie  “Operating  Model”  in 
the  Command  and  Control  (C2)  environment.  The  seope  of  this  paper  is  meant  to  foeus 
attention  on  the  growing  gap  between  current  and  emerging  technological  capabilities 
and  an  operating  construct  to  best  leverage  this  technology. 

It  is  generally  recognized  that  the  introduction  of  new,  transformational  technology  in 
any  context,  combat  operations  or  combat  support  and  business  activities  requires  a 
concomitant  socialization  and  training  on  how  best  to  “use”  the  new  capabilities. 
However,  the  Net-Centric  Operations  and  Warfare  (NCOW)  vision  will  require  new 
doctrine  and  practices  on  how  best  to  optimize  the  technology  for  more  effective 
warfighting  and  combat  support  beyond  a  users  guide.  For  example,  the  invention  and 
introduction  of  the  mechanized  tank  in  World  War  I  was  by  itself  relatively  easy  to 
operate,  but  the  full  potential  of  the  technology  was  not  achieved  until  Tank  Warfare 
Doctrine  was  developed  and  honed  before  and  during  World  War  II. 

This  paper  is  based  on  the  premise  that  in  many  cases  the  technology  “arf’  is  too  far 
ahead  of  the  DoD  policy  and  management  “practice”.  Net-centric  technology  vendors 
offering  products  to  help  in  the  management  aspects  of  network  enabled  systems  and 
services  often  find  their  solutions  are  in  search  of  clearly  defined  problems.  This 
misalignment  exists  because  a  DOD  enterprise  level  NCO  Operating  Model  has  not  been 
clearly  articulated  to  demonstrate  how  consumers  and  providers  of  net-centric  services 
will  interact.  In  addition,  an  underlying  assumption  used  in  this  paper  is  that  net-centric 
technology  and  operating  principles  apply  equally  to  both  to  the  C2  and  combat  support 
(business)  environments.  This  will  provide  a  broader  range  of  concepts  to  demonstrate 
how  to  better  align  the  state  of  the  art  with  the  state  of  the  practice  in  the  C2  arena. 

Consequently,  this  paper  seeks  to  focus  attention  on  how  best  to  develop  the  doctrine  or 
Operating  Model  that  can  tie  the  strategic  vision  of  NCOW  to  the  tactical  functionality  of 
net-centric  technology. 
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What’s  Different  About  This  Transformation? 


Transformation  as  an  organizational  improvement  initiative  has  eome  to  mean  many 
things  to  different  people  and,  in  fact,  be  overused  as  a  term  to  describe  organizational 
direction.  This  occurrence  tends  to  water  down  the  perception  of  the  true  impact  of  any 
specific  initiative  over  time.  Many  past  transformation  initiatives  have  been  untaken 
within  the  existing  context  of  how  operations  are  conducted.  The  introduction  of  new 
technology  and/or  procedures  to  improve  the  enterprise’s  critical  activities  is  done  within 
the  existing  operating  environment.  For  instance,  the  implementation  of  an  Enterprise 
Resource  Planning  (ERP)  application  to  improve  an  organization’s  financial  or  supply 
chain  processes  presumes  many  of  the  processes  embedded  in  the  software  will  be 
adopted  and  adapted  by  that  organization.  In  effect,  the  organization  will  change  some  of 
its  processes  to  optimize  the  technology,  but  in  the  main  will  continue  to  operate  as 
before,  but  hopefully,  marginally  more  efficiently.  Consequently,  enterprise  architecture, 
policy  and  governance,  performance  measurement  standards,  and  social  domain  issues 
are  not  affected.  Organizational  doctrine  remains  unchanged. 

Erom  an  architectural  point  of  view,  especially  within  the  Department  of  Defense  (DoD) 
Architecture  Eramework  (DoDAE),  this  allows  for  a  relatively  straightforward 
articulation  of  the  “To-be”  world.  The  transformation  to  the  desired  end  state  can  be 
represented  as  a  migration  from  a  portfolio  of  known  activities,  systems,  and  capabilities 
(“As-is”)  to  the  To-be  architecture  and  portfolio.  The  marketplace  over  the  last  decade 
has  responded  to  this  paradigm  by  offering  well-defined  technology  packages  that  solve 
easy  to  conceive  (albeit  not  necessarily  execute)  process  improvement  initiatives.  The 
ERP  paradigm  is  a  commoditized  market.  However,  the  success  of  these  packages 
requires  that  the  operating  doctrine  does  not  change  otherwise  the  commodity  will  not 
achieve  economies  of  scale. 

Organizational  policy,  governance,  and  performance  metrics  models  remain  relatively 
constant  in  this  paradigm  as  well.  Improving  a  process  through  better  technology  will 
allow  better  policy  goals’  achievement,  enhance  oversight,  and  increase  performance. 
Other  than  ensuring  expertise  in  operating  the  new  tools,  socialization  issues  are  very 
manageable.  Transformation  is  achieved,  therefore,  when  the  new  status  quo  is  achieved. 

This  is  why  many  past  transformational  efforts  have  not  achieved  truly  revolutionary 
gains  in  effectiveness  or  productivity.  In  some  cases,  a  promising  and  revolutionary  new 
technology  was  sub-optimized  because  it  was  fit  into  the  status  quo  and  no  one  knew  how 
increase  productivity  or  military  effectiveness.  Recalling  the  tank  example  above, 
lacking  any  better  doctrine,  the  tank  was  use  as  infantry  support.  While  dramatically 
effective,  the  technology  was  not  yet  optimized.  In  other  cases,  failure  was  the  result  of 
a  transformational  initiative  reaching  too  far.  An  end  state  was  envisioned  that  could  not 
be  supported  by  either  the  technology  or  the  operating  model.  The  promise  of  an  ERP 
revolutionizing  the  way  business  is  conducted  is  inherently  beyond  the  design  of  a 
commoditized  application  that  was  designed  to  improve  but  maintain  the  status  quo.  In 
sum,  most  recent  transformational  initiatives  have  really  been  incremental  improvements 
whether  in  the  arena  of  combat  or  combat  support  operations. 
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This  is  also  why  the  Net-Centric  transformation  is  different  from  the  past.  First,  the 
emerging  technology  is  not  commoditized.  The  design  concept  of  Service  Oriented 
Architecture  (SOA)  is  focused  on  reusable  and  accessible  packets  of  functionality  that  are 
not  bounded  by  traditional  systems.  There  are  no  built  in  best  practices  to  adapt.  Second, 
the  NCOW  vision  is  enterprise  in  its  scope  and  will  require  an  enterprise  perspective  with 
regards  to  architecture,  policy,  governance,  metrics,  and  cultural  change.  The  net-centric 
vision  is  upsetting  the  exiting  operating  model.  Finally,  the  unfolding  of  the 
transformation  will  be  very  different  and  less  easy  to  articulate  in  traditional  forms  (e.g., 
DoDAF).  As  submitted  above,  transformation  in  the  past  could  be  described  as  achieving 
the  defined  end  state.  In  this  case,  the  end  state  will  be  harder  to  articulate  to  a  high 
degree  of  specificity  we  are  accustomed  to  in  traditional  technology  implementations. 
Consequently,  it  will  be  harder  to  execute  a  transformation  along  the  traditional 
programmatic  linear  path  (i.e.,  define  requirements,  select  technology,  implement  and 
integrate  technology,  train  users,  etc.). 

By  way  of  an  example  that  may  illuminate  the  full  ramifications  of  this  type  of 
transformation  consider  the  invention  of  the  electric  motor.  Its  introduction  to  industry 
did  not  really  create  increased  productivity  gains  until  the  industrial  engineers  of  early 
1900’s  figured  out  how  to  use  it  effectively  to  create  an  assembly  line.^  They  created  a 
new  operating  model  to  unleash  the  full  power  of  the  electric  motor.  However,  this  did 
not  entail  just  moving  employees  from  batch  production  shops  to  assembly  line  ones; 
plant  design,  company-wide  procedures  and  oversight,  performance  metrics,  employee 
training,  and  procurement  practices  all  had  to  be  rethought  and  re-executed.  It  is  quite 
likely  that  there  was  a  fair  amount  of  experimentation  and  it  wasn’t  until  several 
iterations  later  that  the  operating  model  we  see  today  was  settled  upon.  In  other  words, 
the  end  state  was  not  “architected”  and  then  implemented  as  we  have  come  to  expect  with 
a  traditional  technology  projects. 

As  noted  above,  traditional  Command  and  Control  (C2)  and  more  so  combat  support 
systems  are  based  on  the  premise  of  preconceived  and/or  routine  functions  and  access  to 
data  automated  to  achieve  economy  of  scale  efficiencies.  Net-Centric  Operations  and 
Warfare  is  based  on  the  premise  of  supporting  both  the  routine  and  non-routine; 
providing  information  both  structured  and  unstructured,  to  routine  and  unanticipated 
users;  and  leveraging  data  for  both  routine  needs  and  unanticipated  needs.  Consequently, 
the  desired  net-centric  environment  is  inherently  dynamic  it  is  not  possible  to  articulate  a 
definitive  end  state  a  priori.  Specific  portions  of  the  Global  Information  Grid  (GIG) 
systems  architecture  can  and  have  been  defined  (e.g.,  GIG-Bandwidth  Expansion,  Net- 
Centric  Enterprise  Services  (NCES),  Joint  Tactical  Radio  System  (JTRS)),  but 
architecting  the  Net-Centric  Environment  (NCE)  for  DoD  in  DoDAE  is  neither  possible 
nor  necessarily  desirable.  It  is  not  possible  because  the  NCE  will  not  be  a  system  as  in 
the  current  technology  paradigm.  Current  and  emerging  net-centric  technology  and  its 
application  are  demonstrating  pieces  if  the  overall  puzzle  that  contribute  to  the  NCE,  but 
not  as  a  single  enterprise  solution.  It  is  not  desirable  because  to  define  a  system 


'  New  York  Times,  “American  Companies  Show  an  Edge  in  Putting  Information  to  Work”,  12  January 
2006. 
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architecture  in  DoDAF  is  to  define  its  boundaries  which  is  inimical  to  net-centricity.  The 
NCE  will  require  room  to  evolve  over  time  to  take  advantage  of  new  and  better 
technology  and  new  and  more  urgent  requirements.  In  fact,  a  net-centric  environment  is 
one  that  can  adapt  and  should  never  be  too  narrowly  defined. 

However,  a  prescription  to  achieve  the  NCE  must  also  include  more  than  a  technical 
perspective.  The  lesson  of  the  assembly  line  example  is  that  to  harness  the  agility  of  a 
NCE  technology,  DoD  must  also  develop  the  doctrine  that  supports  operating  in  the  agile 
net-centric  world. 

Therefore,  the  net-centric  transformation  can  be  characterized  by  several  key  tenets  that 
should  drive  how  the  transformation  is  managed.  Specifically,  they  are: 

■  The  Net-Centric  Environment  should  not  be  too  tightly  defined  from  an 
architectural  perspective  and  cannot  be  properly  articulated  in  DoDAE.  A  new 
approach  to  enterprise  architecture  will  need  to  be  devised  to  better  articulate  the 
dynamic  nature  if  net-centricity. 

■  A  supporting  operating  model  needs  to  be  established  to  harness  the  people  and 
process  dimensions  of  this  transformation.  Specific  policies,  governance 
structures,  and  metrics  need  to  be  put  in  place  to  modify  behavior. 

■  The  Net-Centric  transformation  is  not  a  linear  process,  but  rather  a  “condition” 
required  to  progress  towards  the  net-centric  vision. 

These  characteristics  will  require  a  different  approach  to  transformation.  Eirst  and 
foremost,  an  operating  model  should  be  initiated  and  evolved  to  better  align  policy  and 
governance  to  technology  decisions.  As  has  been  discussed  above,  this  transformation 
does  not  involve  integrating  proven  technology  and  packaged  applications  into  the  status 
quo.  This  transformation  will  require  technology  decisions  made  on  the  basis  of 
emerging  and  evolving  requirements.  An  operating  model  will  facilitate  creating  these 
requirements  sooner  and  then  serve  to  better  leverage  the  portfolio  of  technology  going 
forward.  The  required  attributes  of  this  model  will  be  presented  in  the  following  section 
of  this  paper. 

Einally,  the  operating  model  cannot  in  all  probability  be  defined  to  any  degree  of 
specificity  at  the  outset.  It  will  require  experimentation.  Experimentation  will  require  a 
laboratory  that  replicates  the  conditions  of  the  envisioned  net-centric  environment.  This 
will  require  creating  these  conditions  in  a  practical  manner  that  can  get  the 
learning/requirements  process  started  to  guide  both  the  development  of  the  operating 
model,  but  also  the  incorporation  of  viable  technologies.  The  last  section  of  this  paper 
will  present  specific  practical  recommendations  to  jumpstart  this  process. 
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What  Is  Needed? 


Design  through  Service  Oriented  Enterprise  Architecture 

A  critical  initial  step  in  transforming  towards  the  net-centrie  vision  is  to  be  able  to 
visualize  for  the  widest  audienee  the  future  state.  DoDAF  has  been  the  standard 
arehiteetural  language  for  several  years.  However,  the  major  drawbaek  of  the  DoDAF 
perspeetive  is  that  it  is  system  foeused,  designed  to  support  the  systems  integrator 
aceomplish  its  task.  The  “entering  argumenf’  in  DoDAF  is  proeesses  and  their 
eonstituent  activities  with  the  output  being  a  system  or  systems  integration  design  to 
provide  funetionality.  In  designing  the  net-eentrie  environment,  entering  argument  will 
need  to  be  functionality  or  services  in  to  order  to  manipulate  data  to  provide  information 
to  the  enterprise.  The  ultimate  goal  is  to  arehitect  an  environment  that  can  accommodate 
unantieipated  users  and  needs  as  well  the  routine.  Although,  traditional  arehiteeture 
views  are  useful,  a  truly  transformational  arehiteeture  eannot  stop  there.  These  two 
design  approaehes  will  have  to  co-exist  in  order  to  transform  to  the  net-eentrie  vision. 

BearingPoint’s  approaeh  to  this  design  challenge  is  to  leverage  both  DoDAF  and  SO  A 
design  prineiples  in  order  to  apply  an  Service  Oriented  Enterprise  Arehiteeture  (SOEA). 
An  SOEA  approaeh  does  not  direetly  deseribe  the  end  state,  but  rather  deseribes  the  three 
eritieal  serviee  areas  neeessary  to  transform  an  organization  and  how  they  should  mature 
over  time  to  aehieve  a  desired  future  state.  Speeifieally,  the  BearingPoint  SOEA 
approaeh  possesses  the  following  eharaeteristics; 

■  The  arehiteetural  proeess  exists  in  a  eontinuum  of  maturity.  BearingPoint  has 
developed  as  part  of  a  team  a  maturity  model  based  on  the  Capability  Maturity 
Model  (CMM).  The  resulting  SOA  Maturity  Model  provides  a  means  to  align 
desired  operational  impact  with  an  organizations  ability  to  accommodate 
ehange. 

■  Eaeilitates  design  of  the  operating  model  for  the  net-centrie  environment  (NCE). 
This  means  deseribing  proeedures  and  proeesses  in  three  key  areas:  1)  Mission 
exeeution  in  the  NCE;  2)  Managing  the  NCE;  and  3)  (given  the  reeognition  of 
inereasing  maturity)  Evolving  the  NCE. 

■  Provides  for  proeess  to  serviee  mapping.  As  noted  above,  serviees  are  the  key 
element  in  the  net-eentric  environment.  However,  human  organizations  still 
accomplish  goals  through  processes.  Consequently,  a  SOEA  must  provide  a 
elear  traeeability  between  these  two  elements.  Additionally,  the  SOEA  will 
need  to  provide  a  elear  mapping  of  serviees  and  legaey/planned  systems. 

■  Establishes  elear  linkage  between  the  arehiteeture  and  portfolio  management 
proeess.  The  SOEA  is  not  an  end-state,  but  rather  a  means  to  aehieve  IT 
portfolio  optimization. 

■  Demonstrates  relationship  of  serviee  providers,  users  and  portfolio  of  serviees. 
Consequently,  the  SOEA  will  eharacterize  services  as  follows: 


7 


o  Functional  Area  Services  -  Those  services  necessary  to  support 
enterprise  activities  and  processes.  They  may  be  enterprise  wide  or 
domain  specific  with  a  people,  Community  of  Interest  (COI)  focus. 

o  Information/Data  Integration  Services  -  Those  services  required  to  make 
data  visible,  accessible,  understandable,  trusted,  and  interoperable  in 
accordance  with  the  DoD  Net-Centric  Data  Strategy. 

o  Network/Communication  Enabling  Services  -  Those  services  necessary 
to  provide  the  physical  infrastructure  for  communication  and  transport 
within  the  enterprise.  The  GIG  infrastructure  and  NCES  initiatives  are 
examples. 


Implementing  in  an  Dynamic  Environment  through  Maturity  Modeling 

As  noted  above,  the  concept  of  maturity  is  critical  to  net-centric  transformation.  Since  it 
will  be  difficult  to  define  the  To-be  state  and  measure  transformation  progress  along  a 
linear  path  of  milestones,  an  alternate,  dynamic  transformation  model  must  be  employed 
in  applying  the  SOEA  approach.  BearingPoint  believes  this  can  be  accomplished  through 
maturity  modeling.  By  combining  definable  and  measurable  levels  of  net-centric 
maturity  with  a  service  oriented  enterprise  architectural  construct  it  will  be  possible  to 
establish  a  reference  model  to  guide  the  transformation  even  though  there  can  be  no  fully 
defined  end  state. 

Consequently,  in  partnership  with  Sonic  Software,  AmberPoint,  and  Systinet, 
BearingPoint  has  developed  the  SOA  Maturity  Model  (SOA  MM)  to  guide  SOA- 
adopting  organizations  in  capturing  the  business  value  of  their  transformation  vision  and 
to  be  able  to  benchmark  SOEA  progress  within  their  organization.  This  streamlined 
process  drives  the  focus  of  initial  SOEA  implementation  appropriately  on  the 
measurement  of  technical  feasibility  and  functional  results. 

The  SOA  MM  delineates  the  approach  to  designing,  implementing,  and  deploying 
information  systems  so  as  to  maximize  the  benefits  to  the  implementing  organization. 
Built  to  leverage  the  success  of  the  CMMI  Maturity  Model  in  providing  a  common 
framework  for  defining  and  assessing  process  improvement  in  software  and  other 
engineering  endeavors,  the  five  levels  of  SOA  Maturity  align  with  the  corresponding 
CMMI  levels,  figure  1  depicts  this  relationship. 
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Figure  1:  Service-Oriented  Architecture  Maturity  Mode! 
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Figure  1:  Service  Oriented  Architecture  Maturity  Model 

Each  Maturity  Level  drives  different  benefits  to  the  organization  and  supports  the  overall 
SOEA  implementation  strategy.  Across  each  Maturity  Level,  the  model  defines  the  key 
attributes  driving  the  measurement  and  evaluation  of  SOA  technology  and  service 
capability.  These  include: 

■  Prime  Mission/Eunctional  Area  Benefits; 

■  Scope; 

■  Critical  Technology  Success  Eactors; 

■  Critical  People  &  Organizational  Success  Eactors; 

■  Selected  Relevant  Standards; 

■  Key  Goals;  and 

■  Key  Practices. 

Therefore,  the  SOA  MM  can  provide  a  benchmark  to  measure  candidate  technologies  and 
facilitate  functional  requirements  development  based  on  desired  Eunctional  Area,  Data, 
and  Network  Services.  Eor  example,  the  Initial  Services  represented  at  SOA  Maturity 
Level  1  represent  the  initial  learning  and  project  phase  of  SOA  adoption.  In  many  current 
instances  this  may  mean  services  are  imbedded  in  standalone  applications  and  are  not 
accessible.  An  initiative  to  move  towards  more  integrated  and  web  based  applications 
will  require  identifying,  refactoring  as  required,  and  architecting  these  services  (Level  2). 
Achieving  the  next  maturity  level  will  also  entail  testing  the  net-centric  technologies  in  a 
laboratory  environment  and  measuring  them  against  the  desired  functionality  of  the 
higher  level. 

The  specific  mechanism  by  which  SOEA  and  maturity  model  are  leveraged  to  manage 
the  transformation  is  through  the  development  and  use  of  a  Service  Reference  Model 
(SRM).  An  SRM  allows  an  enterprise  to  use  the  same  modeling  method  and  patterns  to 
depict  all  its  services  and  processes  across  all  its  subordinate  units.  It  is  the  analytic  tool 
that  provides  a  standardized  and  logical  way  of  mapping  business  processes  so  that  they 
can  be  compared  to  and  aligned  with  their  respective  data  requirements  and  other 
business  processes.  Eigure  2  depicts  an  overview  of  how  a  SRM  helps  align  mission 
operational  goals  to  an  increasingly  mature  SOEA. 
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Figure  2:  SOFA  Service  Reference  Model 
Desired  Attributes  of  an  Operating  Model 

As  noted  above,  the  design  of  the  Operating  Model  must  enable  three  key  aspeets  of  the 
Net-Centrie  Environment.  Speeifieally,  these  are; 

■  Exeeution  of  enterprise  mission  or  funetional  proeesses  and  aetivities; 

■  Management  of  the  overall  NCE;  and 

■  Evolution  of  the  NCE  to  ineorporate  better  teehnologies  and  proeesses. 

In  other  words,  the  Operating  Model  must  allow  warfighting  and  eombat  support 
personnel  to  do  their  job,  manage  the  environment  behind  the  seenes,  and  allow 
eontinuous  improvement  without  disruption  to  eapability. 

The  BearingPoint  approaeh  to  this  ehallenge  is  to  identify  and  address  the  attributes  that 
affeet  the  model’s  ability  to  deliver  these  three  aspeets.  The  main  attributes  are  diseussed 
below: 


■  The  eentral  design  prineiple  of  the  Operating  Model  should  be  a  framework  in 
whieh  serviees  are  provided  and  eonsumed  based  on  warfighter,  intelligenee  and 
business  mission  area  funetional  requirements,  both  ongoing  and  ad  hoe.  This 
NCE  services  “market”  approaeh  is  the  eornerstone  of  the  NCE  as  the  assembly 
line  was  of  the  new  industrial  age.  Execution  of  mission  and  functional  area 
activities  is  facilitated  by  DoD  personnel  entering  the  services  marketplace  and 
“consuming”  required  services.  Suppliers  provide  services  based  on  demand  and 
are  compensated  for  their  provisioning,  innovation,  etc.  by  that  same  demand. 
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■  This  necessitates  a  major  rethinking  oi DoD  acquisition  management.  The  goal 
is  to  create  an  environment  conducive  to  maximizing  both  government  and 
industry  goals  in  a  NCE.  The  creation  of  a  services  marketplace  in  which 
products/services  thrive  or  expire  based  on  their  merit  shifts  the  “buying”  decision 
from  the  tradition  acquisition  processes  to  the  mission  area  consumers  based  upon 
actual  usage  and  quality  of  a  specific  product/service  provided  by  or  demanded  by 
the  services  marketplace.  This  approach  has  significant  regulatory  and  policy 
ramifications. 

■  Governance  mechanisms  to  execute  and  maintain  the  overall  Operating  Model 
will  need  to  account  for  the  provisioning  of  and  access  to  net-centric  services  and 
information,  their  orchestration,  and  performance/quality  of  service  monitoring. 
This  attribute  will  support  the  behind  the  scenes  management  of  the  NCE  and  will 
also  require  new  policies  and  procedures.  Additionally,  this  requirement  will  fuel 
private  sector  research  and  development  of  new  technologies  to  manage  these 
governance  processes. 

■  Net-centric  services  portfolio  management  is  an  extension  of  the  acquisition  and 
governance  features.  Services  portfolio  management  is  a  logical  outgrowth  of  the 
services  marketplace  concept.  Ultimately,  net-centric  services  portfolio 
management  shifts  from  a  subjective,  annual  business  case  development  exercise 
to  an  objective,  metric-based  process  that  can  maximize  the  NCE  and  customer 
satisfaction.  The  net  effect  is  the  minimizing  of  technical  risk  and  cost  by 
harnessing  the  power  of  market  demand,  and  placing  the  responsibility  of 
innovation  on  the  vendor.  This  attribute  not  only  supports  the  management  of  the 
NCE,  but  also  its  evolution.  A  true  metric-based  portfolio  management  process 
can  create  incentives  for  both  consumers  and  providers  of  services  to  act  in  a 
manner  that  enhances  outcomes. 

The  Transformation  Environment 

The  ultimate  outcome  of  leveraging  SOEA  design  principles  to  create  a  net-centric 
Operating  Model  is  not  to  establish  a  static  condition,  a  new  status  quo.  Rather,  the  goal 
is  to  create  a  transformation  environment  or  set  of  conditions  that  ever  improving 
technologies  can  be  rapidly  incorporated  into  the  network  without  major  disruptions  to 
mission  accomplishment.  Consequently,  while  some  aspects  of  the  Operating  Model 
need  to  be  scoped,  defined,  and  built  to  “kick  off’  the  transformation  (e.g.,  service 
monitoring  tools),  not  every  last  detail  can  or  should  be.  The  Operating  Model  will 
create  the  conditions  for  adaptive  behavior. 


^  See  GAO  Report:  DoD  Management  Approach  and  Processes  Not  Well  Suited  to  Support  Development  of 
the  Global  Information  Grid,  January  2006. 
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Practical  Recommendations 


Articulating,  even  arehiteeting  the  Operating  Model  is  a  neeessary  but  not  suffieient  step 
for  transformation.  Critieal  to  its  implementation  is  to  faeilitate  experimentation  that 
allows  praetieal  solutions  to  operating  issues  to  be  identified  and  resolved  to  drive 
requirements  for  future  systems  and  eapabilities.  However,  an  environment  for 
experimentation  does  not  exist. 

For  example,  the  Department  of  Defense  and  the  Serviees  are  attempting  to  align  to 
several  top-down  net-eentrie  transformation  initiatives  (e.g..  Global  Information  Grid 
(GIG),  Net-Centrie  Enterprise  Serviees  (NCES))  and  to  manage  the  introduetion  of 
innovative  eoneepts  involving  Serviee  Oriented  Arehitecture  (SOA)  and  Portfolio 
Management.  However,  these  eoneepts  often  elash  with  the  bottom-up  realities  of  non- 
integrated  solutions,  eustom-developed  applieations,  laek  of  data  visibility,  and  the  eostly 
maintenanee  of  redundant  systems. 

Eurthermore,  DoD  is  struggling  with  an  inability  to  define  To-be  eapabilities  outside  the 
eontext  of  ineremental  improvements  to  today’s  solutions.  Enhaneed  solutions  eompliant 
with  technieal  and  architectural  mandates  ean  only  be  developed  in  an  environment 
where  the  eommunity  understands  the  potential  future  eapabilities  and  can  articulate  their 
business  requirements  in  that  eontext.  To  eompound  the  problem,  the  Department’s 
ability  to  test  and  pilot  the  eoneepts  of  SOA  and  net-eentrieity  using  evolving  teehnology 
is  severely  limited.  As  a  result,  a  large  gap  remains  between  transformation  goals  and 
exeeutable  ehanges  to  C2  or  eombat  support  systems. 

Consequently,  there  is  a  need  for  a  “test-bed”  environment  to  provide  a  means  to 
overeome  these  issues  through  experimentation.  Sueh  a  test  bed  approaeh  must  be  able 
to  simulate  the  conditions  that  would  be  present  in  a  net-eentric  environment  to  aid  in 
visualizing  requirements  net-eentric  solutions. 

Test  Bed  Description 

In  support  to  our  overall  design  approach,  BearingPoint  recommends  a  ereating  a  test  bed 
environment  to  dramatieally  improve  the  quality  of  the  funetional  and  teehnieal 
requirements  provided  to  implementing  ageneies.  A  prototyping  test  bed  is  needed  to 
expand  users’  voeabulary  for  expressing  what  they  need  by  showing  them  a  rieher 
lexieon  of  what  is  possible  when  applying  new  teehnologies  and  teehniques.  With  the 
benefit  of  sueh  a  test  bed,  requirements  for  future  eombat  and  eombat  support  eapabilities 
are  more  likely  to  be  innovative  and  transformational  rather  than  merely  ineremental. 
Instead  of  being  eonfmed  to  speeding  up  the  existing  steps  involved  in  how  work  is  done 
today,  a  prototyping  test  bed  ean  be  used  to  empower  users  to  find  new  ways  to 
aeeomplish  the  same  work  in  less  steps.  Without  sueh  a  test  bed,  requirements  for  future 
systems  will  likely  remain  eonstrained  by  eurrent  views  of  proeesses  and  applications  that 
are  based  on  closed-system  and  point-to-point  integration  arehitectures. 
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By  way  of  analogy  to  visualize  the  value  and  role  of  the  test  bed,  we  see  it  as  similar  to  a 
sand  box  for  ehildren.  The  desired  outeome  of  time  in  the  sand  box  is  fun.  The  main 
ingredient  is  sand.  Faeilitating  serviees  are  the  plastie  tools.  Exaetly  how  the  tools  are 
used  or  what  the  “output”  of  the  time  in  the  sand  box  is  unpredietable.  It  may  be  sand 
eastles,  ditches,  or  random  piles.  In  the  net-centric  test  bed  scenario,  the  sand  is  data;  the 
plastic  tools  are  net-centric  services.  The  net-centric  outcome  equivalent  of  fun  is  a  clear 
set  of  requirements  on  how  the  Operating  Model  can  and  should  work.  The  services 
facilitate  mission  or  business  outcomes  in  totally  unpredictable  ways.  However,  the 
patterns  of  use  constitute  the  Operating  Model. 

Consequently,  the  test  bed  should  provide  the  following  benefits: 

■  Model  the  future  capabilities  to  support  and  improve  the  development  of  NCE  for 
specific  mission  and  functional  areas  in  DoD  with  respect  to  process,  data,  and 
network  requirements, 

■  Demonstrate  future  technologies  to  drive  forward-looking  user  requirements,  and 

■  Test  vendor  solutions  based  on  the  emerging/evolving  requirements  of  a  net- 
centric  environment,  not  in  the  context  of  vendor-defined  parameters. 

Major  Components 

Based  on  our  approach  and  a  current  survey  of  the  technology  marketplace,  BearingPoint 
believes  there  are  several  key  components  necessary  to  make  a  test  bed  environment 
approximate  the  envisioned  NCE  that  can  be  provided  by  the  market  today.  Eogically, 
these  components  must  either  provide  or  simulate  services  that  fall  into  the  categories 
discussed  above  (i.e.,  Eunctional  Area,  Data/Information,  and  Network  Services). 
Additionally,  each  component  should  be  able  to  simulate  a  desired  level  of  maturity  in 
accordance  with  the  proposed  SOEA  Service  Reference  Model  (see  Eigure  2,  above)  in 
order  to  test  various  alternative  scenarios.  The  output  of  the  mission  or  functional  “use 
case”  is  a  set  of  process,  data,  and  network  requirements  that  better  define  the  emerging 
Operating  Model. 

Therefore,  grouping  the  test  bed  components  accordingly,  we  recommend  the  following 
capabilities: 

■  Eunctional  Area  Services  Components  -  The  components  in  this  group  serve  to 
replicate  and/or  simulate  the  specific  mission  or  functional  area  “use  case”  that  is 
being  analyzed  for  transformation. 

o  User  Experience  -  This  module  provides  the  practical  user  interfaces 
tailored  to  the  specific  use  case  to  be  tested.  At  a  lower  level  of  maturity 
(e.g.,  stand  alone  applications)  the  test  bed  will  leverage  legacy  processes 
and  systems.  At  a  higher  level  of  maturity  (e.g.,  applications  as  services) 
this  module  will  need  to  simulate  service  capabilities  and  processes. 
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o  Future  State  Modeling  -  This  module’s  funetion  is  to  monitor,  eapture, 
and  doeument  the  behavior  of  use  ease  partieipants  in  various  seenarios. 
This  module  is  eritieal  to  generate  the  outputs  that  will  help  deseribe  and 
demonstrate  the  emerging  Operating  Model. 

■  Data/Information  Serviees  Component-  The  purpose  of  this  eomponent  is  to 
replieate  and/or  simulate  the  data  environment  envisioned  in  the  Net-Centrie 
Data  Strategy.^  Depending  on  the  level  of  maturity  to  be  simulated  this 
eomponent  will  provide  the  test  bed  environment  with  a  range  of  behind  the 
seenes  data/information  integration  levels  from  the  eurrent  state  of  stand  alone 
information  to  semantie  web  eapabilities  to  make  data  visible,  aeeessible,  and 
understandable. 

■  Network  Serviees  Component  -  The  role  of  this  eomponent  is  to  replieate  (and 
where  possible  leverage)  the  emerging  GIG  Enterprise  Serviees  (GES) 
infrastrueture  underlying  the  NCE  to  inelude  seeurity/information  assuranee, 
serviees  orehestration,  and  serviee  quality  monitoring.  Many  of  the  governanee 
meehanisms  of  the  overall  Operating  Model  are  provided  in  this  eomponent. 

With  these  eomponents  in  plaee,  the  test  bed  environment  ean  be  employed  to  model  and 
test  the  SOEA  with  various  seenarios  of  teehnology  introduetion,  investment,  and  risk. 


^  DoD  Net-Centric  Data  Strategy,  9  May  2003. 
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Conclusion 


The  transformation  of  combat  and  combat  support  systems  and  processes  towards  a  Net- 
Centric  Environment  is  an  extremely  complicated  and  multi-faceted  challenge.  The 
marketplace  does  not  currently  offer  commoditized  solution  technologies  or  proven 
methodologies  to  facilitate  this  transition  in  a  manner  that  maintains  alignment  between 
theoretical  capabilities  and  practical  necessities.  However,  by  taking  an  enterprise 
perspective  to  the  dynamic  design  issues  and  applying  practical  experimental  techniques, 
DoD  can  better  create  the  conditions  for  net-centric  transformation  and  ensure  alignment 
between  the  state  of  the  art  and  the  state  of  the  practice. 
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